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Abstract 


A BGP speaker performing policy based on the Resource Public Key Infrastructure (RPKD should 
not issue route refresh to its neighbors because it has received new RPKI data. This document 
updates RFC 8481 by describing how to avoid doing so by either keeping a full Adj-RIB-In or 
saving paths dropped due to ROV (Route Origin Validation) so they may be reevaluated with 
respect to new RPKI data. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 


on it may be obtained at https://www.rfc-editor.org/info/rfc9324. 
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1. Introduction 


Memory constraints in early BGP speakers caused classic BGP implementations [RFC4271] to not 
keep a full Adj-RIB-In (Section 1.1 of [RFC4271]). When doing RPKI-based Route Origin Validation 
(ROV) [RFC6811] [RFC8481] and similar RPKI-based policy, if such a BGP speaker receives new 


RPKI data, it might not have kept paths previously marked as Invalid, etc. Such an 


implementation must then request a route refresh [RFC2918] [RFC7313] from its neighbors to 
recover the paths that might be covered by these new RPKI data. This will be perceived as rude 


by those neighbors as it passes a serious resource burden on to them. This document 


recommends implementations keep and mark paths affected by RPKI-based policy, so route 
refresh is no longer needed. 
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1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


2. Related Work 


It is assumed that the reader understands BGP [RFC4271], route refresh [RFC7313], the RPKI 
[RFC6480], Route Origin Authorizations (ROAs) [RFC6482], the Resource Public Key Infrastructure 
(RPKI) to Router Protocol [RPKI-ROUTER-PROT-v2], RPKI-Based Prefix Validation [RFC6811], and 
Origin Validation Clarifications [RFC8481]. 


Note that the term "RPKI-based Route Origin Validation" in this document means the same as the 
term "Prefix Origin Validation" used in [RFC6811]. 


3. ROV Experience 


As Route Origin Validation dropping Invalids has deployed, some BGP speaker implementations 
have been found that, when receiving new RPKI data (Validated ROA Payloads (VRPs) [RPKI- 
ROUTER-PROT-Vv2]), issue a BGP route refresh [RFC7313] to all sending BGP peers so that they can 
reevaluate the received paths against the new data. 


In actual deployment, this has been found to be very destructive, transferring a serious resource 
burden to the unsuspecting peers. In reaction, RPKI-based Route Origin Validation (ROV) has 
been turned off. There have been actual de-peerings. 


As RPKI registration and ROA creation have steadily increased, this problem has increased, not 
just proportionally, but on the order of the in-degree of ROV implementing BGP speakers. As 
Autonomous System Provider Authorization (ASPA) [AS_PATH-VER] becomes used, the problem 
will increase. 


Other mechanisms, such as automated policy provisioning, which have flux rates similar to ROV 
i.e., on the order of minutes), could very well cause similar problems. 


Therefore, this document updates [RFC8481] by describing how to avoid this problem. 


4. Keeping Partial Adj-RIB-In Data 


If new RPKI data arrive that cause operator policy to invalidate the best route and the BGP 
speaker did not keep the dropped routes, then the BGP speaker would issue a route refresh, 
which this feature aims to prevent. 
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A route that is dropped by operator policy due to ROV is, by nature, considered ineligible to 
compete for the best route and MUST be kept in the Adj-RIB-In for potential future evaluation. 


Ameliorating the route refresh problem by keeping a full Adj-RIB-In can be a problem for 
resource-constrained BGP speakers. In reality, only some data need be retained. If an 
implementation chooses not to retain the full Adj-RIB-In, it MUST retain at least routes dropped 
due to ROV for potential future evaluation. 


As storing these routes could cause problems in resource-constrained devices, there MUST be a 
global operation, CLI, YANG, or other mechanism that allows the operator to enable this feature 
and store the dropped routes. Such an operator control MUST NOT be per peer, as this could 
cause inconsistent behavior. 


As a side note, policy that may drop routes due to RPKI-based checks such as ROV (and ASPA, 
BGPsec [RFC8205], etc., in the future) MUST be run and the dropped routes saved per this section, 
before non-RPKI policies are run, as the latter may change path attributes. 


5. Operational Recommendations 


Operators deploying ROV and/or other RPKI-based policies should ensure that the BGP speaker 
implementation is not causing route refresh requests to neighbors. 


BGP speakers MUST either keep the full Adj-RIB-In or implement the specification in Section 4. 
Conformance to this behavior is an additional, mandatory capability for BGP speakers 
performing ROV. 


If the BGP speaker does not implement these recommendations, the operator should enable the 
vendor's control to keep the full Adj-RIB-In, sometimes referred to as "soft reconfiguration 
inbound". The operator should then measure to ensure that there are no unnecessary route 
refresh requests sent to neighbors. 


If the BGP speaker's equipment has insufficient resources to support either of the two proposed 
options (keeping a full AdjRibIn or at least the dropped routes), the equipment SHOULD either be 
replaced with capable equipment or SHOULD NOT be used for ROV. 


The configuration setting in Section 4 should only be used in very well-known and controlled 
circumstances where the scaling issues are well understood and anticipated. 


Operators using the specification in Section 4 should be aware that a misconfigured neighbor 
might erroneously send a massive number of paths, thus consuming a lot of memory. Hence, pre- 
policy filtering such as described in [MAXPREFIX-INBOUND] could be used to reduce this 
exposure. 


If route refresh has been issued toward more than one peer, the order of receipt of the refresh 
data can cause churn in both best route selection and outbound signaling. 
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Internet Exchange Points (IXPs) that provide route servers [RFC7947] should be aware that some 
members could be causing an undue route refresh load on the route servers and take 
appropriate administrative and/or technical measures. IXPs using BGP speakers as route servers 
should ensure that they are not generating excessive route refresh requests. 


6. Security Considerations 


This document describes a denial of service that Route Origin Validation or other RPKI policy 
may place on a BGP neighbor and describes how it may be ameliorated. 


Otherwise, this document adds no additional security considerations to those already described 
by the referenced documents. 


7. IANA Considerations 


This document has no IANA actions. 
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